This application was re-filed after May 29, 2000 and pursuant to 37 C.F.R. xc2xa71.53(d) to define a continued prosecution application (CPA) which continues from U.S. Ser. No. 09/438,135, filed Nov. 10, 1999.
1. Field of the Invention
The invention relates generally to computer systems that concurrently execute plural application programs on a preemptive multitasking basis.
The invention is directed more specifically to multitasking systems wherein the execution of a given application program, and more specifically a network-browsing program or the like, may become frozen or may otherwise halt unexpectedly and for which it is desirable to revive the frozen/halted application program at least to a state which enables nonvolatile saving of work product produced so far by the frozen program. The invention is directed even more specifically to the problem of how to appropriately locate and save work product items of a just-froze browser program or the like so that a fresh copy of the program can be relaunched and made to automatically re-link with the just-saved work product.
2a. Cross Reference to Related Patents
The disclosures of the following U.S. patents are incorporated herein by reference:
(A) U.S. Pat. No. 5,911,060 issued Jun. 8, 1999 to Scott Elliott, and entitled, COMPUTER METHOD AND APPARATUS FOR UNFREEZING AN APPARENTLY FROZEN APPLICATION PROGRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM; and
(B) U.S. Pat. No. 5,974,249 issued Oct. 26, 1999 to Scott Elliott et al, and entitled, ZERO FOOTPRINT METHOD AND APPARATUS FOR EXPANDING ALLOCATED MEMORY SPACE OF A PROCESS USING A VIRTUAL MEMORY AREA.
2b. Cross Reference to Co-pending Patent Applications
The disclosures of the following Co-pending, U.S. patent applications (each owned by the owner of the present application) are incorporated herein by reference:
(A) U.S. Ser. No. 08/938,204, filed Sep. 26, 1997, by inventor Scott Elliott, which application later issued as U.S. Pat. No. 6,009,258, entitled METHODS AND DEVICES FOR UNWINDING STACK OF FROZEN PROGRAM AND FOR RESTARTING THE PROGRAM FROM UNWOUND STATE;
(B) U.S. Ser. No. 09/275,171, filed Mar. 24, 1999 as a divisional of U.S. Ser. No. 08/937,629, filed Sep. 26, 1997 by inventor Scott Elliott, which application later issued as U.S. Pat. No. 6,151,569, entitled AUTOMATED SEQUENCE OF MACHINE-PERFORMED ATTEMPTS TO UNFREEZE AN APPARENTLY FROZEN APPLICATION PROGRAM; and
(C) U.S. Ser. No. 09/438,076, filed concurrently herewith by inventors Scott Elliott and Jeff Carr and originally entitled METHODS FOR AUTOMATICALLY LOCATING DATA-CONTAINING WINDOWS IN FROZEN APPLICATION PROGRAM AND SAVING CONTENTS.
2c. Copyright Notice
This application includes one or more listings of computer programs. The assignee of the present application claims certain copyrights in said computer program listings. The assignee has no objection, however, to the reproduction by others of these listings if such reproduction is for the sole purpose of studying it to understand the invention. The assignee reserves all other copyrights in said program listings including the right to reproduce the corresponding computer programs in machine executable form.
3. Description of Related Art
Multitasking computer systems may be characterized as those that allow multiple programs to execute in overlapping fashion so that it appears the programs are all running at the same time.
Preemptive multitasking systems may be characterized as those in which an operating system (OS) has supervisory control over the concurrently executing programs and the OS limits the length of time that each given application program has for using system resources such as a CPU (Central Processing Unit) or other data processing means.
Examples of preemptive multitasking OS""s include Microsoft Windows95(trademark), Microsoft Windows98(trademark) and Microsoft Windows NT(trademark), all of which are available from Microsoft Corporation of Redmond, Wash. These OS""s also permit multi-threaded execution of programs. In multi-threaded execution, a program begins executing as a first, main thread and optionally generates ancillary threads that run concurrently and interact with one another through exchanges of semaphores.
During execution, a given application program, and more specifically a network-browsing program, may encounter an unexpected problem which halts its normal execution either in a main thread or an ancillary thread. Examples of causes for such problems include those in which: (a) the program attempts to access restricted (privileged) or unavailable areas of memory areas, (b) the program makes calls to unavailable system functions or services without the ability to handle such unavailability, (c) the program jumps into a nonsense stream of execution code, (d) the program invokes a no-time-out wait for an event that never happens, (e) the program enters into a deadlock embrace, and so forth. This is a nonexhaustive list of possible causes.
When such execution-halting events occur, artisans sometimes refer to the halted program as being xe2x80x98stuckxe2x80x99 or xe2x80x98frozenxe2x80x99 or xe2x80x98crashedxe2x80x99 or as having encountered a xe2x80x98fatal errorxe2x80x99. Different flavors of these terms are sometimes associated to one class of cause as opposed to another. Here, the terminology xe2x80x98frozen applicationxe2x80x99 will be generically applied to any and all situations in which the user of a given application program reasonably believes the program is stuck and that this perceived state prevents saving of work product irrespective of the exact cause and irrespective of whether the user""s belief is accurate in fact. Also herein, the terminology xe2x80x98recently-froze applicationxe2x80x99 will be generically applied to any and all application programs which meet the definition of having become frozen at least once in the past and of not having been fully revived or launched afresh.
The end-user (e.g., novice user) of a computer system typically doesn""t care what the specific cause is that has led him or her to believe that they can no longer save work product. Such a user instead generally recognizes the xe2x80x98frozenxe2x80x99 condition as an apparently sudden or recent refusal by the given application program to respond appropriately to keyboard strokes or to mouse clicks or to other user interface interactions (which interactions can include voice commands, hand gestures, and so forth).
The presence of a frozen program does not generally pose a major problem to the overall operations of a preemptive multitasking system. In such systems, other, concurrently-executing application programs can continue to run in normal fashion even though a given application (e.g., the network-browser) has actually become frozen or has actually crashed (as opposed to situations where the program is fine and the user merely believes it has become stuck). The end-user continues to have access to operating system services and to the resources of non-frozen application programs. (For example, in a Windows95/98(trademark) environment the user may hit the Alt-Tab key combination to switch to the next task.) The user may choose to simply end the tasking of the apparently-frozen program and to thereafter restart the program afresh from its basic start-up state.
Sometimes, this close-and-restart-afresh option is not an attractive one for the end-user. It may be that the end-user did not, or believes he did not, save to nonvolatile memory (e.g., to hard disk), a segment of work product that he/she last generated with the application just before the given application became frozen. Closing-and-restarting the frozen program afresh may mean that the unsaved work may be lost forever or that the user will have to repeat many hours of work to thereby painfully reconstruct the state of the application program just before it apparently became frozen. In some instances, the pre-freeze state of the application may represent non-replicatable work product such as data that had just been captured and/or transformed in real-time.
To remedy this predicament, various un-freezing techniques have been developed. These try to revive the frozen/crashed program at least to a sufficient level such that unsaved work product may be accessed and saved either wholly or partially. Examples of such un-freezing techniques include those disclosed in the above-cited patents and patent applications.
Despite significant progress in the art of un-freezing programs that are apparently frozen, no currently known unfreezing technique is 100% effective for all possible forms of application program and all possible situations. One may make an analogy to attempts to revive a human patient by CPR (cardio-pulmonary resuscitation) after the patient suffers a cardiac arrest. In some cases, the patient is fully revived by a given CPR method. In other cases, the patient is revived but still suffers from serious complications. And in yet further cases, even heroic attempts to revive the patient with all known manners of CPR regretfully prove unsuccessful.
The above analogy to application of CPR on human beings breaks down fairly rapidly and should therefore not be taken to extremes. In so far as reviving a frozen application program is concerned, the end goal is not necessarily to keep the application program alive and happily working as long as possible, but rather to keep the machine-executed program alive long enough so that vital, but still unsaved, work product can be saved.
One un-freezing technique tests the apparently-frozen application to see if the cause of the freeze is a xe2x80x98soft eventxe2x80x99 (where the application continues to respond to messages from the OS) or a xe2x80x98hard eventxe2x80x99 (where the application is not longer responding to messages from the OS). If it is a xe2x80x98soft eventxe2x80x99, the un-freezing technique may try to CLOSE or CANCEL the currently xe2x80x98activexe2x80x99 window under the theory that such an xe2x80x98activexe2x80x99 window is simply a hidden dialog box that is expecting a user response, but is not getting it because the user does not see the hidden dialog box.
If the cause of the freeze is determined to be a xe2x80x98hard eventxe2x80x99, the un-freezing technique may try to continue the execution of the frozen application program by entering the execution stream of the frozen program at a point where continued execution will probably preserve the application""s state just before the encounter with the freeze-causing event. However, even if this attempt is fully or partially successful, the long-term health of the defrozen application program may be questionable and it may be wise to save its work product and re-start the program afresh. Determining specifically what data within the just-froze (and possibly-revived) program should be saved and exactly how to go about saving it is still a problem.
Network-browsing programs tend to be particularly difficult to revive because many of their operations occur as background dispatches out of a xe2x80x98periodic-peekingxe2x80x99 style message loop. (The background dispatches can include continued resolving of HTML source code and continued decompression of GIF, JPEG or other graphic image code. The periodic peeks look for user-inputs such as clicks on screen buttons, in which case responding to the user-input (e.g., go BACK to previously visited site) takes precedence over continued servicing of the background dispatches.) Because of such factors, and generally speaking, when a network-browsing program freezes, there is a good likelihood that it will not be successfully returned into a fully operational state, and the user will have to terminate the program and re-launch it afresh.
Conventionally, after a revival technique is applied to a xe2x80x98hardxe2x80x99 failure event, a message is sent to the user to go ahead and try to immediately save their work product to nonvolatile memory and to then immediately shut down the application program. In some instances, the end user finds that these instructions are very easy to follow. The application program appears to be fully resuscitated and the end user may quickly forget that the program just suffered may have been a serious problem. The user may be able to easily maneuver the cursor to a SAVE BOOKMARK function on the program""s menu bar and to invoke an address-saving operation that saves an address of a network site that the user had last navigated to. Sometimes the user may be so lucky as to be able to continue working as if nothing wrong had just happened, although such continuing of work defies the instructions given to the user.
In other cases, the end user""s ability to follow the post-revival instructions turns out to be more complicated. The end user may find that mouse-driven functions of the program such as, SAVE FILE, or ADD BOOKMARK, or ADD TO FAVORITES, have become inoperative. The user may not know what else to do for saving navigation or other work product data. Also, the user may have multiple web sites open or multiple other work product objects (e.g., filled-in fields of a boiler-plate form document) left open and in need of saving. The user may become confused and try to use inoperative parts of the just-revived program instead of immediately saving all unsaved work product.
More specifically, if the frozen application program is an Internet browser program such as Microsoft Internet Explorer(trademark), or Netscape Communicator(trademark), or Netscape Navigator(trademark) and the user has arduously navigated through many Web search results and/or through many hyperlinks to establish a current navigation history, then it can be quite disappointing to have the browser suddenly freeze up on the user. A novice user may simply panic and click on the application CLOSE button (the uppermost, right corner xe2x80x98Xxe2x80x99 button) thereby terminating the frozen browser before any data is saved. A more experienced user may have the presence of mind to first copy onto a piece of paper, the current URL text (Universal Resource Locator) from the current address box before terminating so that he/she can at least navigate back to that last site. However, even such a more experienced user may make a transcription error and fail to properly log the full text of his/her current URL.
The present invention provides methods and systems which may be used as automated alternatives to leaving it to an end user to manually control the work product saving process in a just-froze browser or like application program. While the above example of a problem focused on the saving of a URL, the invention may extend to the saving of other forms of data as may be presented in multiple windows (e.g., edit-control windows). This broader aspect will be elucidated upon below.
A number of separate aspects of a multi-threading, windows-oriented operating system (OS) are employed here. These include: detection of a possible freeze and optional attempts at reviving an apparently-frozen program, analysis of the parent/child windows hierarchy in a just-froze program, and automatic passing of messages to appropriate child windows to cause the program of those windows to transfer their data contents to another program so that the data contents can be saved before the just-froze program is terminated or otherwise manipulated.
When an un-freeze request is presented, and a QuickSave or QuickReload(trademark) option is selected (QuickReload(trademark) is a trademark of Symantec Corp.), an appropriate revival procedure (which could include doing nothing) may be automatically selected and carried out. As part of the QuickSave or QuickReload(trademark) operation, an automatic identification is made, in accordance with the invention, of one or more windows of the just-froze (and possibly-revived) program, where the identified windows are those that most probably contain (immediately in such identified windows), vital data that the user would most likely want to save for later use. In particular, the vital data of interest can be URL (Universal Resource Locator) text or other network address data that would allow the user to easily return to Internet Web sites or other network locations that have been visited without requiring the user to engage in a lengthy re-navigation through the network to find those sites again. Additionally or alternatively, the vital data of interest can be edit-control data such as may be found in the multiple-windows of an e-commerce fill-in form. For example, when a computer user begins to make a commercial transaction (or a like other transaction) over the Internet or another network, the transaction procedure may ask the user to fill-in or make choices within a lengthy form that asks for one or more of the user""s first name, last name, postal address, email-address, home and business telephone numbers, shopping cart contents, and so on. The user""s filled-in or chosen data is typically held as data within multiple and respective, edit-control windows, as will be detailed below. Such edit-control data can be identified and saved in accordance with the invention so that it may be re-represented to the user for filling in a post-crash, new form.
One of a number of alternate techniques (e.g., GetDialogItemText( ) and GetWindowText( )) may be used to cause the frozen (e.g., crashed) program (e.g., browser) to itself fetch and send the vital data (e.g., current URL or forms entry) to a debugger running in an independent thread so that the debugger can obtain and save the vital data before the frozen program is terminated or otherwise manipulated. Thereafter, even if revival attempts do not succeed, a fresh copy (a newborn copy) of the program that froze (or a substitute of like capabilities) may be automatically launched and the saved vital data (e.g., current URL) may be automatically sent to the newborn program for causing that newborn program (e.g., browser) to act upon that vital data. The end user is thereby given the impression that he or she is right back where they were just before the crash or other freeze occurred. Alternatively, a list of saved data may be presented (e.g., in a NotePad(trademark) window) to the user for user-guided, and selective, copying and pasting of such data into appropriate edit-control or other windows in the newborn program.
A machine-implemented, quick-saving and reloading method in accordance with the invention can comprise one or more of the steps of: (a) optionally attempting to revive a program that has apparently become frozen and/or identifying that apparently-frozen program; (b) identifying one or more windows within the just-froze (and possibly-revived) program that are most likely to immediately contain therein data which the user is likely to consider as vital and in need of saving; (c) causing the just-froze (and possibly-revived) program (e.g., browser) to itself fetch and send the vital data (e.g., current URL, form entries) to a debugger running in an independent thread so that the debugger can save the vital data; (d) terminating the frozen program; (e) automatically launching a fresh copy (a newborn copy) of the program that froze or launching a substitute program (e.g., a browser from another vendor); and (f) transferring the saved vital data to the launched program.
Other features and aspects of the invention will become apparent from the below detailed description.